Statically tracking state with Typed Regions

Static type systems have proved to be tremendously effective formal systems, making specification and verification sufficiently lightweight and intuitive that most programmers use them without even realizing it. Not only that, but they have shown to adapt very well to most modern language features. The downside is that the properties one can express and verify with garden variety type systems is fairly limited, especially concerning properties which depend on side-effects and tracking the state of objects. Such properties usually require the use of other formal methods, such as some kind of Hoare logic [Hoare 1969; Reynolds 2002], which are targeted specifically at reasoning about imperative programs. And it so happens that those alternative formal methods do not always integrate well with modern language features such as higher-order functions, and polymorphism. The work presented here presents a new type system which has an expressive power comparable to that of a Hoare logic, thus hopefully combining the best of both worlds. As the technology of certifying compilation and proof carrying code [Necula 1997; Appel 2001; Hamid et al. 2002] progresses, the need to ensure the correctness of the runtime system increases: the carefully designed proof system risks breaking down completely if one of the primitives of the runtime system does not behave exactly as intended. The best way to approach this problem is to trim down the trusted part of the runtime system, starting with the garbage collector. For this reason, it is important to be able to write a verifiably type-safe GC, which may come bundled with the application code, rather than hard-coded in the trusted runtime system. but the state of the art in this matter is still very much impractical. So one of this paper’s main goal is to present a type system that is sufficiently flexible and powerful to type-check low-level code such as stack manipulation, pointer reversal, or the various parts of a generational garbage collector. This type system provides a form of assignment that can change the type of a location (i.e. a strong update [Chase et al. 1990]) even if the set of aliases to this location is not statically known, and it allows the programmer to choose any mix of linear or intuitionistic typing of references and to seamlessly change this choice over time to adapt it to the current needs. Traditional type systems are not well-suited to reason about type safety of low-level memory management such as explicit memory allocation, initialization, deallocation, or reuse. Existing solutions to these problems either have a very limited applicability or rely on some form of linearity constraint. Such constraints tend to be inconvenient and a lot of work has gone into relaxing them. For example, the alias types system [Walker and Morrisett 2000] is able to cleanly handle several of the points above, even in the presence of arbitrary aliasing, as long as the aliases can be statically tracked by the type system. Traditional type systems mostly ensure memory safety. But of course, when typing low-level memory management code, proving that the code does not break the memory safety invariants often amounts to the same as proving that the code is correct. For this